laikafandomcom-20200214-history
Programmer Guidelines
Unity Basics #Our language of choice is C#. In some cases it might be okay to use an external script written in javascript, but it should probably be discussed with the rest of the programming team first. #When working on a new feature or testing something out, always create a new scene to test it in. Never change the existing scenes directly, unless it's part of the task. The scene you create should also be commited (in the correct folder), since it can be used to test the feature by itself at a later point, as well as help other people understand how it works. #Use prefabs as far as possible and reasonable. #Never commit a broken 'build. Broken here means that it doesn't run, or breaks something other than what you're working on. Incomplete features can be commited (for versioning purposes or if cooperating with someone else) as long as they don't break anything else. Code Style #Basic code formatting ('indentation, placement of brackets) should follow the C# standards so there is no need to go into further details here. Both Visual Studio and MonoDevelop can autoformat code. #Use CamelCasing for identifiers (names of classes, properties, fields, methods, variables, ...). If including an abbreviation that is normaly all uppercase, only uppercase the first letter or none at all (e.g. GUI becomes Gui '' or ''gui depending on position and usage). Use an underscore to group different aspects of the same thing (e.g. PinkDuck_Beak and PunkDuck_Feet or MyButton_Click and MyButton_DoubleClick). #'Classes', Properties, and Methods 'should start with an '''uppercased letter '(e.g. SomeMethod) #'''Fields '''and '''local variables should start with a''' lower case letter', and then be camel cased from there on (e.g. someField) #Don't include '''variable type' in variable names (e.g. don't call something resultString, just result will do). #As a rule of thumb, use properties for publicly exposed values. If it needs to be exposed in the Unity inspector, however, you need to use a field. #Use descriptive and meaningful identifiers, but also keep them as short as possible. Prefer not to abbreviate. Strive to avoid use of lyrics and/or titles from pop music. #One class per file. #Describe complex code passages with comments, but don't add comments for every single thing the code does. Comments should describe what the idea '''behind code is, or the algorithm used, not state again what the code already says. #If it's not immidiately obious what a method or class does, add a comment above the method and briefly describe it. Example of correct casing: class BeSomething { public int SetANumber { get; set; } private int someValue; public DrawMyGui() { string ducksCanFly; } } Best Practices #Always keep the codebase '''clean '''and easy to understand. It's better to spend two minutes of your time tidying something up, than causing other people to spend a long while trying to understand what something is supposed to do. #Strive for '''reuseability and avoid having code that does the same thing in multiple places. #If a class starts to become very large, consider whether some of the code is general and can be moved to other places. If not, split the class into regions for readibility. Perhaps the class is responsible for many different behaviours, in which case it would make sense to split each behaviour into a different script. Repository Etiquette #If you change the build (this includes adding stuff, changing parameters, moving files), make sure it runs and works reasonably before you commit it. #Always describe '''what you have changed/added in commits, short and descriptively, in the comment field. #If you make an asset '''obsolete, either by replacing it or simply not using it anymore, delete it before committing to clean the project clean. Of course, only delete something if it's truly obsolete, not if you expect it to be used at a later point. #Strive to keep the project clean '''at all times. Spending 2 minutes cleaning something up could save you or someone else hours of work later. #Feel free to add '''new folders to the project if it helps organization. Category:Browse Category:Guidelines